Dynamically building subsections of locale objects at run-time

ABSTRACT

Subsections of locale objects are dynamically built from locale source files when requested at run-time without building all subsections of the locale object. When a subsection of a locale object is dynamically built, the subsection is stored in global memory so it may be read by multiple applications. Dynamically building subsections of locale objects when requested allows software to operate with a relatively small number of locale objects instead of with hundreds or thousands of locale objects, as is known in the art, and requires fewer system resources because only the requested subsection of the locale object is built when it is requested. The result is significant savings in system-wide resources while still allowing for access to a large number of possible locales.

BACKGROUND

1. Technical Field

This disclosure generally relates to computer systems, and morespecifically relates to locale objects that support software used indifferent languages and cultures.

2. Background Art

For computer software to be useful it must be capable of presentinginformation which reflects the users' cultural preferences, such aslanguage and conventions, and allow users to interact with the softwareaccording to their preference. One way to account for different languageand conventions is to customize software for a specific market, such asa geographical region or country. Such customized software is relativelyinflexible in allowing users to alter the cultural or languagepreference of the software to meet particular needs. Therefore, in orderto market software internationally, significant expense may be incurredin customizing the software for each individual international market andproviding technical support and updates.

Great effort has been expended to make software “internationalized”,which means the software may be easily and readily adapted to differentlanguages and cultures. An internationalized application program has nobuilt-in assumptions with respect to the cultural preference of itsusers or the data it is to process or present. Rather, it allows theuser to specify the language or conventions of the information used tointeract with the application and the language or conventions in whichthe information is presented by the application.

The establishment of ISO/IEC 9945-1:1990 (IEEE Standard 1003.2-1990)Information Technology-Portable Operating System Interface (POSIX™)Shell and Utilities provided a vehicle for the development of portableapplications. IEEE Standard 1003.1 describes a set of basic systemservices for input/output, file system access, and process management tobe used in the development of application programs. The standard alsodefines an interface accessible from the C programming language, whichprovides access to these services and establishes standard semantics andsyntax. This interface allows application program developers to writeportable applications in the C programming language.

In compliance with IEEE Standard 1003.1, IEEE Standard 1003.2 wasdeveloped to facilitate the internationalization of applications whichdid not require the application program developer to customize theapplication program for each cultural market. IEEE Standard 1003.2defines a source code level interface to shell services and commonutilities which is independent of IEEE Standard 1003.1. An extension ofthis standard is the User Portability Extension (UPE) (IEEE Standard1003.2a) that addresses interactive terminal-oriented utilities such asfull screen editors.

The IEEE Standards 1003.2 and 1003.2a are based on a “locale” modelwhich provides the binding methodology for combining user preferencesfor language and conventions with the functions of the internationalizedapplication program at run-time. The locale model describes the user'slanguage or conventions to the application program and conveys it to theapplication program at run-time so that the data is processed andpresented correctly according to the needs of the user. Locale objectsare typically packaged with software to provide the needed support fordifferent locales.

Some software includes a great number of different locale objects. Forexample, the C/C++ Run-Time Library for the z/OS operating systemdeveloped by IBM ships with over 2,000 different locale objects.Building and maintaining such a large number of locale objects requiressignificant cost and resources, especially when typical computingenvironments will only need a few locale objects.

BRIEF SUMMARY

Subsections of locale objects are dynamically built from locale sourcefiles when requested at run-time without building all subsections of thelocale object. When a subsection of a locale object is dynamicallybuilt, the subsection is stored in global memory so it may be read bymultiple applications. Dynamically building subsections of localeobjects when requested allows software to operate with a relativelysmall number of locale objects instead of with hundreds or thousands oflocale objects, as is known in the art, and requires fewer systemresources because only the requested subsection of the locale object isbuilt when it is requested. The result is significant savings insystem-wide resources while still allowing for access to a large numberof possible locales.

The foregoing and other features and advantages will be apparent fromthe following more particular description, as illustrated in theaccompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

The disclosure will be described in conjunction with the appendeddrawings, where like designations denote like elements, and:

FIG. 1 is a block diagram of an apparatus that includes a dynamic localeobject builder;

FIG. 2 is a block diagram of an example prior art locale object;

FIG. 3 is a block diagram of a prior art operating system showing localeobjects packaged with operating system code;

FIG. 4 is a flow diagram of a prior art method for building localeobjects and packaging the locale objects with the operating system code;

FIG. 5 is a block diagram of a prior art system showing building oflocale objects for packaging with operating system code during themanufacturing of the operating system;

FIG. 6 is a flow diagram of prior art method for installing the priorart operating system shown in FIG. 3;

FIG. 7 is a flow diagram of a prior art method for loading a localeobject into the memory of a calling computer program and accessingsubsections of the locale object as needed;

FIG. 8 is a block diagram of an operating system packaged with a mastercharacter map and locale source files;

FIG. 9 is a flow diagram of a method for packaging the master charactermap and locale source files with operating system code as shown in FIG.8;

FIG. 10 is a flow diagram of a method for installing the operatingsystem shown in FIG. 8;

FIG. 11 is a flow diagram of a method for dynamically building a localeobject when requested;

FIG. 12 is a block diagram of a system for dynamically building localeobjects at run-time;

FIG. 13 is a flow diagram of a method for pre-loading a small definedset of locale objects on system boot; and

FIG. 14 is a flow diagram of a method for dynamically building arequested subsection of a locale object when requested without buildingall subsections of the locale object.

DETAILED DESCRIPTION

As described in the Background Art section above, a “locale” modelprovides the methodology for combining user preferences for language andconventions with the functions of an internationalized applicationprogram at run-time. The locale model defines six categories of culturalvariables, which are collectively referred to as “locale categories”:(1) character attributes and mappings; (2) character collation; (3)monetary formatting; (4) numeric data formatting; (5) date and timeformatting; and (6) messages. Values are specified for each of thelocale categories which particularizes the type of formatting to beapplied to the data to be processed or presented. For example, possiblevalues for the locale category “monetary formatting” would be UnitedStates (dollar), Japan (yen), etc. which would result in the monetarydata being formatted to be processed or presented according to thecurrency of the specified country. When the six locale categories areassigned specific values, they are collectively referred to as a“locale”. The locale categories are referenced by the applicationprogram as the application program is executed. One known locale object210 shown in FIG. 2 is suitable for use with programs written in theC/C++ programming language. Locale object 210 includes a categoryLC_CTYPE 220 that provides information relating to characterclassification and case conversion. A category LC_COLLATE 230 providesinformation relating to collation order. A category LC_MONETARY 240provides information relating to monetary formatting. A categoryLC_NUMERIC 250 provides information relating to numeric, non-monetaryformatting. A category LC_TIME 260 provides information relating to dateand time formats. A category LC_MESSAGES 270 provides informationrelating to formats of informative and diagnostic messages andinteractive responses. Once the locale object 210 is loaded into thememory of a software application that needs information in the localeobject 210, the software application may invoke any of the categories inthe locale object as needed. Because the prior art locale object 210 iswell-known in the art, additions details of the prior art locale object210 are not included here. One specific example for prior art localeobject 210 is a Portable Operating System Interface (POSIX) localeobject.

Referring to FIG. 3, a prior art operating system 300 is shown, whichincludes operating system code 310 and locale objects 320. The operatingsystem code 310 may include any suitable operating system code orfunction. Other features of operating system 300 not specifically shownin FIG. 3 are presumed to be present in the operating system code 310.The representation in FIG. 3 simply shows an operating system 300shipped to a customer for installation on a computer system typicallyincludes multiple locale objects 320. Individual locale objects 330 areshown in FIG. 3 as locale S 330A, locale T 330B, . . . , locale X 330N.

FIG. 4 shows a prior art method 400 for building locale objects andpackaging locale objects with operating system code. A locale sourcefile is selected (step 410). A locale source file as known in the art isa file that includes text for each of the six locale categories shown inFIG. 2, which uniquely define a set of cultural and linguistic standardsor preferences. A locale source file must be processed by a localeobject builder to build a locale object. Returning to FIG. 4, acharacter map is selected (step 420). A locale object is then built fromthe selected locale source file and the selected character map (step430). When there are more locale source files to process (step 440=YES),method 400 loops back to step 410 and continues. When there are no morelocale source files to process (step 440=NO), all of the locale objectscreated in steps 410-440 are packaged with the operating system code(step 450), with the result as shown in FIG. 3.

FIG. 5 shows a system 500 for performing method 400 in FIG. 4. A localeobject builder 550 builds locale objects 320, shown in FIG. 5 as localeS 330A, locale T 330B, . . . , locale X 330N from character maps 510 andlocale source files 530. Thus, locale object 330 could be built by thelocale object builder 550 from charmap A 520A and locale source file M540B. Locale object 330B could be built from charmap K 520N and localesource file L 540A. Because the locale objects 320 are packaged with theoperating system code as shown in FIG. 3, the locale object builder 550is run at the factory where the operating system is manufactured. Thus,prior art system 500 is part of the operating system manufacturingprocess, and is not performed at run-time of the operating system.

Prior art method 600 in FIG. 6 is a method that shows what happens whenthe operating system 300 shown in FIG. 3 is initially installed on acomputer system. First, the operating system code is installed (step610). All of the locale objects packaged with the operating system arethen stored into the file system of the operating system (step 620).Method 600 is then done. Many operating systems and applications mayinclude a large number of locale objects, hundreds or even thousands. Asstated above in the Background Art section, C/C++ Run-Time Library forthe z/OS operating system developed by IBM ships with over 2,000different locale objects. Practical experience shows that most operatingsystem installations will need fewer than ten locales, with some needingonly a few. Yet all of the locales packaged with the operating system,even hundreds or thousands of locales, are stored into the file systemof the operating system in step 620. Storing thousands of locales in thefile system when only a few are needed results in a substantial waste ofsystem resources in the file system.

As shown in FIG. 7, once the operating system is loaded and running, alocale for the operating system may be set by invoking the setLocale( )function (step 710). The setLocale( ) function is typically invoked byan application that needs locale information. The requested localeobject is loaded into the memory of the application that invoked thesetLocale( ) function (the “caller's memory”) (step 720), and thecalling application calls the subsections of the locale object as needed(step 730). Method 700 is then done. Because the locale object is loadedinto the memory of the calling application in step 720, when tendifferent applications are running that all need to access the samelocale object, the result will be the replication of the locale objectten times in the memory of each calling application. Note theterminology herein for step 730 is that an application “calls”subsections of the locale object, which is consistent with how localeobjects are discussed in the prior art. However, locale objects aretext-like files that provide locale information, and normally there isno executable code in a locale object. For this reason, when anapplication calls, invokes or references a subsection of a localeobject, the application is simply reading text information from thesubsection of the locale object, and is not calling executable code.

Pre-building hundreds or thousands of locale objects and packaging thosehundreds or thousands of locale objects with an operating system orapplication requires substantial effort and resources to both generateand maintain the operating system or application. This is furtherexacerbated by the fact that one locale source file may be used to buildmultiple locale objects. For example, one locale source file could beused with an American Standard Code for Information Interchange (ASCII)character map to build a first locale object. The same locale sourcefile could be used with an Extended Binary Coded Decimal InterchangeCode (EBCDIC) character map to build a second locale object. The samelocale source file could be used with a Unicode character map to build athird locale object. This simple example illustrates how a computerprogram can have hundreds or thousands of locale objects that are builtfrom a much smaller set of locale source files.

The claims and disclosure herein provide a way to dynamically buildsubsections of locale objects from locale source files when requested atrun-time without building all subsections of the locale object. When asubsection of a locale object is dynamically built, the subsection isstored in global memory so it may be read by multiple applications.Dynamically building subsections of locale objects when requested allowssoftware to operate with a relatively small number of locale objectsinstead of with hundreds or thousands of locale objects, as is known inthe art, and requires fewer system resources because only the requestedsubsection of the locale object is built when it is requested. Theresult is significant savings in system-wide resources while stillallowing for access to a large number of possible locales.

Referring to FIG. 1, a computer system 100 is one suitableimplementation of a server computer system that includes a dynamiclocale object builder. Server computer system 100 is an IBM zEnterpriseSystem computer system. However, those skilled in the art willappreciate that the disclosure herein applies equally to any computersystem, regardless of whether the computer system is a complicatedmulti-user computing apparatus, a single user workstation, or anembedded control system. As shown in FIG. 1, computer system 100comprises one or more processors 110, a main memory 120, a mass storageinterface 130, a display interface 140, and a network interface 150.These system components are interconnected through the use of a systembus 160. Mass storage interface 130 is used to connect mass storagedevices, such as local mass storage device 155, to computer system 100.One specific type of local mass storage device 155 is a readable andwritable CD-RW drive, which may store data to and read data from a CD-RW195.

Main memory 120 preferably contains data 121, an operating system 122,global memory 127, and one or more applications 129. Data 121 representsany data that serves as input to or output from any program in computersystem 100. Operating system 122 is a multitasking operating system.Operating system 122 includes a master character map 123, locale sourcefiles 124, and a dynamic locale object builder 125. One suitableimplementation of the master character map 123 is a master character mapbased on Unicode because Unicode is a superset of all other encodings.This allows other character maps to be dynamically generated from themaster character map 123 as needed. The dynamic locale object builder125 receives requests from applications 129 at run-time, and inresponse, identifies a needed character map and one of the locale sourcefiles, generates the needed character map from the master character map123, then dynamically builds at least one of the locale objects 128 fromthe generated character map and locale source file. The locale objects128 are stored in global memory 127, which means memory that can be readby multiple applications. The locale objects 128 have a structuredefined by the locale source file used to build each locale object. Inone specific implementation, the locale source files 124 and the localeobjects 128 have the same categories shown in the prior art localeobject 210 shown in FIG. 2.

Computer system 100 utilizes well known virtual addressing mechanismsthat allow the programs of computer system 100 to behave as if they onlyhave access to a large, contiguous address space instead of access tomultiple, smaller storage entities such as main memory 120 and localmass storage device 155. Therefore, while data 121, operating system122, global memory 127, and applications 129 are shown to reside in mainmemory 120, those skilled in the art will recognize that these items arenot necessarily all completely contained in main memory 120 at the sametime. It should also be noted that the term “memory” is used hereingenerically to refer to the entire virtual memory of computer system100, and may include the virtual memory of other computer systemscoupled to computer system 100.

Processor 110 may be constructed from one or more microprocessors and/orintegrated circuits. Processor 110 executes program instructions storedin main memory 120. Main memory 120 stores programs and data thatprocessor 110 may access. When computer system 100 starts up, processor110 initially executes the program instructions that make up operatingsystem 122. Processor 110 also executes the dynamic locale objectbuilder 125 in operating system 122.

Although computer system 100 is shown to contain only a single processorand a single system bus, those skilled in the art will appreciate that adynamic locale object builder may be practiced using a computer systemthat has multiple processors and/or multiple buses. In addition, theinterfaces that are used preferably each include separate, fullyprogrammed microprocessors that are used to off-load compute-intensiveprocessing from processor 110. However, those skilled in the art willappreciate that these functions may be performed using I/O adapters aswell.

Display interface 140 is used to directly connect one or more displays165 to computer system 100. These displays 165, which may benon-intelligent (i.e., dumb) terminals or fully programmableworkstations, are used to provide system administrators and users theability to communicate with computer system 100. Note, however, thatwhile display interface 140 is provided to support communication withone or more displays 165, computer system 100 does not necessarilyrequire a display 165, because all needed interaction with users andother processes may occur via network interface 150.

Network interface 150 is used to connect computer system 100 to othercomputer systems or workstations 175 via network 170. Network interface150 broadly represents any suitable way to interconnect electronicdevices, regardless of whether the network 170 comprises present-dayanalog and/or digital techniques or via some networking mechanism of thefuture. Network interface 150 preferably includes a combination ofhardware and software that allow communicating on the network 170.Software in the network interface 150 preferably includes acommunication manager that manages communication with other computersystems 175 via network 170 using a suitable network protocol. Manydifferent network protocols can be used to implement a network. Theseprotocols are specialized computer programs that allow computers tocommunicate across a network. TCP/IP (Transmission ControlProtocol/Internet Protocol) is an example of a suitable network protocolthat may be used by the communication manager within the networkinterface 150.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

Referring to FIG. 8, the operating system 122 includes operating systemcode 810 packaged with the master character map 123 and locale sourcefiles 124. The operating system code 810 could be the same as prior artoperating system code 310 shown in FIG. 3, or could be different code.The master character map 123 is preferably a single character map fromwhich all other needed character maps may be generated. The localesource files 124 could be the same as the locale source files 530 shownin FIG. 5, or could be different than the prior art locale source files530. Locale source files 124 include multiple individual locale sourcefiles 830, shown in FIG. 8 as 830A, 830B, . . . , 830N. The localesource files 124 can have any suitable configuration, including thecategories in prior art locale object 200 shown in FIG. 2. FIG. 9 showsa method 900 that packages the master character map and locale sourcefiles with the operating system code (step 910). By packaging the mastercharacter map 123 and locale source files 124 with the operating systemcode 810 as shown in FIG. 8, locale objects may be dynamically built atrun-time as described in detail below.

A method 1000 in FIG. 10 is performed when the operating system isinitially installed on a computer system. The operating system code isinstalled (step 1010). The master character map and locale source filesthat were packaged with the operating system are then stored into thefile system (step 1020). Method 1000 is then done. Because the number oflocale source files is significantly less than the number of localeobjects, and because the only character map packaged with the operatingsystem is the master character map 123, the result is a reduction in thesize of the operating system 122 when compared to prior art operatingsystem 300 shown in FIG. 3. This makes the operating system 122 easierto create and maintain.

Referring to FIG. 11, a method 1100 is performed when an applicationprogram requests a locale (step 1110) to gain access to localeinformation. Note the request can take the form of a request for theentire locale object, or a request for one or more subsections of thelocale object. If the requested locale is not already built (step1120=NO), the locale source file corresponding to the requested localeobject is identified (step 1130). The needed character map isdynamically generated from the master character map (step 1135). Therequested locale object is then dynamically built from the generatedcharacter map and the identified locale source file (step 1140). Thelocale object is then loaded into global memory (step 1150). Asdiscussed above, the term “global memory” as used herein means memorythat can be read by multiple application programs. By loading therequested locale object into global memory, the requested locale objectmay be read by all applications that need access to it, thereby reducingthe memory space needed to store locale objects. A reference to thelocale object is then returned to the requesting application (step1160), which references subsections of the locale object as needed (step1170). Method 1100 is then done.

Referring to FIG. 12, a system 1200 illustrates the building of localeobjects at run-time. The dynamic locale object builder 125 functions inaccordance with locale requests received from applications. When alocale request is received by the dynamic locale object builder 125, theappropriate character map is generated from the master character map123, the appropriate locale source file is identified, and the charactermap and local source file are used to dynamically build a correspondinglocale object 128. Individual locale objects are shown in FIG. 12 aslocale S 1210A, locale T 1210B, . . . , locale X 1210N. Note that system1200 in FIG. 12 is similar in some respects to prior art system 500shown in FIG. 5. However, the differences are significant. Prior artsystem 500 in FIG. 5 builds locale objects at the location where theoperating system is being manufactured, not where the operating systemruns at the customer site. System 1200 in FIG. 12 dynamically buildslocale objects as needed at run-time. Prior art system 500 builds localeobjects upon command by a human operator. System 1200 builds localeobjects when they are requested at run-time by an application. Prior artsystem 500 builds locale objects from a human operator selecting acharacter map and a locale source file. System 1200 builds local objectsdynamically from a character map dynamically generated from a mastercharacter map, and from a locale source file specified in a call from anapplication. By dynamically building locale objects as needed atrun-time, the number of locale objects shipped with the operating systemis vastly reduced, while still providing the flexibility to use anylocale object when needed.

In one particular implementation, at initial program load (system boot),the operating system has no locale objects and must build the neededlocale objects. One way to accomplish this is shown in method 1100 inFIG. 11, building one locale object at a time as requested by anapplication. In an alternative implementation, the operating systemcould build a small defined set of locale objects when the operatingsystem starts up, thereby eliminating the need to dynamically build thelocale objects in the small defined set when requested by anapplication. Such an implementation is shown in method 1300 in FIG. 13.Method 1300 begins at system boot (step 1310). A small defined set oflocale objects is determined (step 1320). The defined set of objectscould be stored, for example, in a database table or other datastructure. If all of the locale objects in the small defined set alreadyexist (step 1330=YES), method 1300 is done. The locale objects in thesmall defined set may already exist, for example, when the localeobjects are persisted. When the locale objects in the small defined setdo not already exist (step 1330=NO), the small defined set of localeobjects is dynamically built (step 1340). Method 1300 is then done. Notethat method 1300 in FIG. 13 could be used in conjunction with method1100 in FIG. 11. A simple example will illustrate. Let's assume localeobjects are not persisted in a computer system that is initialized. Withthis assumption, the system boots in step 1310, the small defined set oflocale objects are determined in step 1320, and because these localeobjects do not already exist (because they are not persisted) (step1330=NO), they are dynamically built (step 1340). Method 1100 could thenbe performed to dynamically build any other needed locale objects whenrequested by an application. Method 1300 thus adds flexibility inallowing locale objects to be built when an operating system starts up.

FIG. 11 shows one particular method 1100 of operation for the dynamiclocale object builder 125 shown in FIG. 1. Method 1100 in FIG. 11dynamically builds an entire locale object, including all of itssubsections, when any subsection of the locale object is requested. FIG.14 shows an alternative method 1400 of operation for the dynamic localeobject builder 125 that builds only a requested subsection of a localeobject without building other subsections of the locale object. Method1400 begins with an application requests a locale subsection (step1410). When the requested subsection has already been built (step 1420),the requested subsection is loaded into global memory (step 1450), and areference to the locale object subsection is returned to the requestingapplication (step 1460). The requesting application then references therequested subsection as needed (step 1470). When the requestedsubsection of the locale object has not been built (step 1420=NO), thelocale source file corresponding to the requested subsection isidentified (step 1430), the needed character map is generated from themaster character map (step 1435), and the requested subsection of thelocale object is dynamically built from the generated character map andlocale source file without building other subsections of the localeobject (step 1440). In other words, only the requested subsection of thelocale object is built in step 1440. Contrast this to step 1140 in FIG.11, where the entire locale object is dynamically created, including allof its subsections. The requested subsection of the locale object isthen loaded into global memory (step 1450), a reference to the localeobject subsection is returned to the requesting application (step 1460),and the requested subsection is referenced by the requesting applicationas needed (step 1470). Method 1400 is then done. Building only therequested subsection of the locale object instead of building the entirelocale object, including all its subsections, saves on processing timeand system storage used, thereby enhancing system performance.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

While a POSIX locale object is shown in FIG. 2, the disclosure andclaims herein expressly extend to any type of locale source file andlocale object, whether currently known or developed in the future. Inaddition, while the examples in this disclosure (such as shown in FIG.8) show an operating system packaged with a master character map andlocale source files, this is by way of example. Any suitable computerprogram could be packaged with character maps and locale source files sothe dynamic locale object builder can build locale objects dynamicallyat run-time. The disclosure and claims herein thus expressly extend to adynamic locale object builder in any type of software, whether currentlyknown or developed in the future. In addition, instead of using a mastercharacter map 123 to generate needed character maps at run-time, priorart character maps, such as those shown in FIG. 5, could also be used.

The claims and disclosure herein provide a way to dynamically buildsubsections of locale objects from locale source files when requested atrun-time without building all subsections of the locale object. When asubsection of a locale object is dynamically built, the subsection isstored in global memory so it may be read by multiple applications.Dynamically building subsections of locale objects when requested allowssoftware to operate with a relatively small number of locale objectsinstead of with hundreds or thousands of locale objects, as is known inthe art, and requires fewer system resources because only the requestedsubsection of the locale object is built when it is requested. Theresult is significant savings in system-wide resources while stillallowing for access to a large number of possible locales.

One skilled in the art will appreciate that many variations are possiblewithin the scope of the claims. Thus, while the disclosure isparticularly shown and described above, it will be understood by thoseskilled in the art that these and other changes in form and details maybe made therein without departing from the spirit and scope of theclaims.

1. A computer-implemented method executed by at least one processor forbuilding a requested subsection of a requested locale object atrun-time, the method comprising the steps of: receiving a request forthe requested subsection of the requested locale object from a softwareapplication at run-time; identifying at least one of a plurality oflocale source files corresponding to the requested locale object;dynamically building the requested subsection of the requested localeobject from the identified at least one locale source file withoutbuilding all subsections of the requested locale object; loading therequested subsection of the requested locale object into a memory; andreturning to the software application a reference to the requestedsubsection of the requested locale object.
 2. The method of claim 1wherein each of the plurality of locale source files includes aplurality of subsections and the requested locale object includes theplurality of subsections that includes the requested subsection.
 3. Themethod of claim 2 further comprising the step of the softwareapplication referencing the requested subsection in the requested localeobject as needed.
 4. The method of claim 2 wherein the plurality ofsubsections includes: a first subsection that includes informationrelating to character classification and case conversion; a secondsubsection that includes information relating to collation order; athird subsection that includes information relating to monetaryformatting; a fourth subsection that includes information relating tonumeric, non-monetary formatting; a fifth subsection that includesinformation relating to date and time formats; and a sixth subsectionthat includes information relating to formats of informative anddiagnostic messages and interactive responses.
 5. The method of claim 1wherein the step of loading the requested subsection of the requestedlocale object into the memory comprises the step of loading therequested subsection of the requested locale object into global memorythat may be read by a plurality of software applications.
 6. The methodof claim 1 further comprising the step of building a defined set oflocale objects at system boot.
 7. The method of claim 1 furthercomprising the steps of: determining when the requested subsection ofthe requested locale object has already been built; and not building therequested subsection of the requested locale object when the requestedsubsection of the requested locale object has already been built.
 8. Acomputer-implemented method executed by at least one processor forbuilding a subsection of a requested locale object at run-time, themethod comprising the steps of: building a defined set of locale objectsat system boot; receiving a request for the subsection of the requestedlocale object from a software application at run-time; when therequested locale object has already been built, performing the steps of:loading the requested locale object; and returning to the softwareapplication a reference to the requested subsection of the requestedlocale object; when the requested locale object has not already beenbuilt, performing the steps of: generating an identified character mapfrom a master character map; identifying at least one of a plurality oflocale source files corresponding to the requested locale object, eachof the plurality of locale source files including: a first subsectionthat includes information relating to character classification and caseconversion; a second subsection that includes information relating tocollation order; a third subsection that includes information relatingto monetary formatting; a fourth subsection that includes informationrelating to numeric, non-monetary formatting; a fifth subsection thatincludes information relating to date and time formats; and a sixthsubsection that includes information relating to formats of informativeand diagnostic messages and interactive responses; dynamically buildingthe requested subsection of the requested locale object from theidentified character map and from the identified at least one localesource file; loading the requested subsection of the requested localeobject into global memory that may be read by a plurality of softwareapplications; and returning to the software application the reference tothe requested subsection of the requested locale object.